1. Field of the Invention
The present invention relates to a method and a device for exchange of information between documents loaded by a user agent such as a web browser. In particular, the present invention relates to exchange of event related data between documents when such exchange is otherwise precluded by security policies.
2. Description of Background Art
In order to provide more dynamic content to applications that access content from a network such as the Internet, a number of improvements and extensions to the various protocols and standards used have been introduced over the years. Some of these standards include Cascading Style Sheets (CSS), Document Object Model (DOM), various extensions and alternatives to the Hypertext Markup Language (HTML), including Dynamic HTML, Extensible HTML (XHTML), and various programming and scripting languages such as Java, PHP, JavaScript, ECMAscript etc. (Java and JavaScript are trademarks of Sun Microsystems, Inc.)
The World Wide Web Consortium (W3C) defines DOM as a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page.
ECMAscript is a standard for scripting languages, more commonly known as JavaScript. A client side script is code embedded in or imported into a document in order to be executed on the client computer on which the document is displayed. It is different from server side scripts, which execute on the server and embed the results in a document before the document is transmitted. A typical example of a server side scripting language is PHP, but even JavaScript can be used to create server side scripts.
For simplicity the term script will be used hereinbelow to refer to any executable script or program code that is embedded in or imported into a document in order to be executed on the client computer or device, regardless of the actual scripting language used.
As already mentioned, DOM defines interfaces allowing scripts and programs to access and update documents. However, for security reasons there are strict limits imposed on how and which data a script is allowed to access or exchange with another script. A script runs within the scope and context of a specific document with which it is associated, and has access to this document using standard methods. In this sense the document and the script may be understood as a single unit.
That is not to say that a script cannot be reused. Scripts can for example be stored in separate files locally or on a server and imported into documents, but the instance of the script that is so imported becomes part of the document, and has a separate identity from any other instance of the same script even if originating from the same file and from the same domain.
According to DOM, (X)HTML and XML structures are organized into a hierarchical model. This model is made up of DOM nodes that can be addressed using standardized DOM interfaces. The nodes themselves are data objects, and they are related to each other in a well organized tree of nodes where the root node represents the document itself.
Access to nodes, including nodes belonging to different documents, may take place using so called events. An event is a software message that indicates that something specific has happened. The message is “fired” or “posted” by a function that detects the occurrence or fulfillment of certain conditions and the target for the message is a DOM node. Event-driven languages, such as JavaScript and ECMAscript, register various functions on the referenced node (i.e. the receiving node). These functions may be referred to as event handlers or event listeners and they are designed to receive the posted event, process and/or act upon it, and output a result.
Hereinbelow, unless otherwise specified, the word event may be used to cover the condition or occurrence that triggers the posting of the event message, or the event message itself. This will allow for simpler language. Following this terminology it will be possible to say that when an event occurs in one node, it may be received by an event handler in another node. This involves an abstraction that hides the fact that the event that occurs may be very different from the data received by the event handler, but this will be readily understood by a person skilled in the art.
As mentioned above, a script is associated with a document and has access to this document using standardized methods, but data exchange outside the scope of the document is severely restricted. According to the JavaScript security model, the requirement for Cross Domain Event Communication to take place is that the documents are able to refer to each others DOM Document object nodes using DOM interfaces (“DOM Document reference”). However, they cannot necessarily access the content of the DOM Document object.
Such a reference can for instance be created when one document creates a HTML OBJECT element and directs a user agent (e.g. a browser) into which it is loaded, to load a different document into the OBJECT. In this case the parent DOM document can refer to the DOM document within the OBJECT tags, the child document, using standardized methods. The child document can also refer to the parent DOM document using standardized methods.
One limitation imposed by the JavaScript security model, which is a typical security policy in a browser environment, is that scripts running in two documents from different origins may not interact. When a document is loaded from one origin and a script is running within a document loaded from a different origin, the script cannot get or set any properties of certain objects in the first document. The origin is defined by the user agent as the substring of a URI that includes protocol://host, where host also includes the optional :port part of the string. Table 1 shows some examples of comparisons with the URI http://company.com/dir/page.html.
TABLE 1URLOutcomeReasonhttp://company.com/dir2/other.htmlSuccessSame domain,different directoryhttp://company.com/dir/inner/another.htmlSuccessSame domain,differentsubdirectoryhttp://www.company.com/dir/other.htmlFailureDifferent domainsfile://D|/myPage.htmFailureDifferentprotocolshttp://company.com:8080/dir/etc.htmlFailureDifferent port
There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. In this case the shorter domain is used for subsequent origin checks. For example, a script in the document at http://www.company.com/dir/other.html could execute the following statement:
document.domain=“company.com”;
After execution of that statement, the page would pass the origin check with http://company.com/dir/page.html.
The same origin requirement reduces flexibility and functionality for developers of applications and of content, particularly for highly mobile environments where functionality and content from a number of different providers should be integrated and able to interoperate. As an example, on mobile devices such as mobile telephones and PDAs user applications, interfaces and content may be a result of a combination of features and data delivered from the manufacturer of the device, a network operator, software providers and content providers.
With the restrictions imposed by the DOM interfaces and script security policies the necessary flexibility is difficult to achieve.